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The invention pertains to a universal motion controller, with engineering 
and run time systems, that functionally combines the classic tasks of a 
5 programmable logic controller and a numerical controller. 

It is customary today to model different hierarchical run levels both for the 
PLC and for the motion controller, and to allocate to those run level software 
tasks for controlling a given technical process. While these tasks can fulfill 
10 system requirements, they can also be programmed by the user. 

It is known that for a programmable logic controller "PLC," and thus for a 
motion controller "NC" as well, user programs or tasks created by the user can 
be loaded into the memory of a particular controller and executed there. 

15 

From DE 197 40 550 A1 , it is known that process control functionalities of 
programmable logic controllers "PLC" and motion functionalities of an NC 
controller can be integrated into a uniform configurable controller system, 

20 This PLC/NC integration takes place by interconnecting the PLC and NC 

controller assemblies. When integration is achieved in this way, however, an 
optimal and efficient task structure for the entirety of the controller tasks is not 
obtained. In addition, expanded functionality with respect to the process 
controller, and thus with respect to the motion controller, can be loaded and 

25 executed only in the form of user programs. 

It is customary today to provide controllers with parameterization 
information. In this context, parameterization information includes 

- the description of system variables with data type, attributes, and descriptive 
30 texts, 

- the description of alarms, with their structure, attributes, and alarm texts, and 
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- the description of commands (motion and technology commands) with syntax 
and relevant parameters. 

Typically, however, this parameterization information, which is needed at 
5 different locations within the controller, is implemented separately at each of 
those locations in the controller. It requires a very great effort to ensure the 
consistency of this parameterization information implemented at different 
locations. 



10 The objective of the invention is the creation, in a simple manner, of 

optimal configurations for the combined PLC/NC controllers in respect to both 
their controller structure and their functionality for different controller tasks and 
the different constraints or requirements of the underlying technical process, thus 
ensuring that the parameterization information implemented in the controller is 

15 always internally consistent. 

The invention attains this objective with a uniform run level model 
designed to have several run levels of different types with different priorities, 
where various user and system-levels ranging from highest to lowest priorities 

20 are provided, so that technology packets can be loaded by the user into the 
engineering and/or run time systems and so that a data source makes 
commands and/or system variables available to the engineering system via a 
converter for descriptive information for system variables and, as needed, alarms 
and/or commands, so that the system variables with current technical process 

25 data are available from the run time system and additional input can be made by 
the user via a user interface for the engineering system. 

A significant advantage of this invention is that the parameterization 
information for the controller, which is needed both in the engineering system 
30 and in the run time system, as well as for documentation and the possibility of 
test automation, is always consistent. The converter, which prepares and 
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distributes the parameterization information from a central location for 
documentation, the engineering system, and the run time system, can perform 
semantics checks without great effort. OEM (original equipment manufacturer) 
customers can also create additional parameterization information in this data 
source for descriptive information, that is, at a defined location, without great 
effort and incorporate it into the documentation. 

An additional advantage of the invention is that the controller tasks can be 
arranged within the run levels so as to reduce the effort required for 
communication within the controller. 

An additional advantage is that, as a result of the loading of technology 
packets into the engineering and/or run time systems of the controller, the user 
can obtain user-specific scaling of the controller's run time system with respect to 
its functionality. 

An initial advantageous configuration of the invention is that relevant 
documentation information from the data source can be forwarded by the 
converter to an output medium. This ensures that ail documentation information 
originates from a common data source and is thus always internally consistent, 
regardless of the output medium (for example, printer or online help) on which 
the documentation information is output. 

An additional advantageous configuration of the invention is that the 
following run levels are provided: 

a) a position-control level, consisting of associated clocked system-level and 
user-level, 

b) an interpolator level, consisting of associated clocked system-level and user- 
level, 

c) an event system-level for events requiring response. 
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d) a user-level for asynchronous errors, 

e) an additional user-level, freely plan-able by the user for specific requirements, 
for alarm and/or event and/or control and/or other cyclical tasks, 

f) a group of levels made up of a series of motion sequences, free cycles, and 
5 other low-priority system tasks, for background processing, 

where run levels a to e form a group of levels for real-time processing. 

A significant advantage of this arrangement in levels is that 
10 communication between the process controller tasks and those of the motion 
controller is minimized. As a result, the controller tasks for the process controller 
and for the motion controller can be programmed in a uniform programming 
language with a uniform generation interface. 

15 An additional advantageous configuration of this invention is that the 

technology packets contain: 

a) code parts that represent the control specifics for the run time system, and 

b) a configuration part that shows the allocation of these code parts to each of 
20 the system-levels and the order in which they are processed, where 

c) this information of the configuration part can also be forwarded to the 
engineering system as needed. 

This gives the user the possibility of a technological scaling of the controller's run 
25 time system as a result of the dynamic loading of such technology packets. 
Thus, starting from a basic system of the controller, the user can expand the 
supply of commands for this basic system or operating system in a way that is 
dynamically tailored to the particular requirements of the underlying technological 
process or controller task. Thus, the user has the possibility of expanding the 
30 available basic functionality of a controller to include precisely those 

functionalities that s/he really needs for her/his applications. In this case, the 
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base system forms the scope of operations of the run time system of a controller, 
namely, a real-time operating system, a run time system (with system and user- 
levels), technology object types, commands, and the PLC command supply, as 
well as communication (for example, LAN, E/A) and technological interfaces (for 
5 example, drives, emitters) for the technical process. The basic system thus 
includes the necessary basic functionality of a controller. The basic system can 
be run on a wide range of HW platforms (for example, PC, drive,...). 

Given that the information in the configuration part of a technology packet 
10 can be transferred via the data source and converter into the run time system 
and the engineering system, parameterization and configuration information can 
be imported into the controller in a uniform fashion, and a user can make 
changes to the parameterization and configuration data from a central location. 
This parameterization information corresponds to data descriptions for the usual 
15 general aspects of the controller, namely, system variables, alarms, and 
commands. Configuration information, on the other hand, refers to the 
technology packets and thus to the possibility of technological scaling for a 
controller. 

20 Given that each technology packet contains an adjusted number of 

technology object types for the run time system, it is possible to load even 
complex and sophisticated controller functionalities into the run time system in a 
clear and comprehensible form. 

25 An additional advantageous configuration of the invention is that user 

interface information, especially control parameters, and/or programming 
language features and/or declaration parts can be allocated to the code parts. 
This results in the following advantages: In order to be able to use a technology 
object type as more than just a constant that can no longer be changed, the 

30 technology object type must inform the generating system of the possibilities of 
parameterization for its instantiated technology objects and particularly the 
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available operating parameters. Thus, a user has the possibility of flexibly 
parameterizing a technology object in the generating system's interface. 



Given that programming language features can also be loaded, it is 
5 possible that the available command library of the run time system can be 

dynamically expanded. In a user program, the user can use a command loaded 
in this way as if it were a command from the base functionality of the base 
system. When a user program is processed with a command loaded in this way 
within a user-level of the run level model, the associated code sequence of the 
10 operating system is processed on one of the system-levels of the run level model 
when this loaded command is called up. This takes place without any action on 
the part of the user. The user's flexibility is further increased by the allocation of 
the declaration and description parts to the code parts of the technology packet. 



15 A sample configuration of the invention is presented in shown in the 

figures, as explained in below. 



FIG 1 shows the control of a technical process with separate PLC and 

motion controller. Programming is accomplished via separate 
20 programming systems. 

FIG 2 shows the significant run levels of a classic PLC. 

FIG 3 shows the significant run levels of a motion controller. 

FIG 4 shows a universal controller, that is, a combined PLC/NC controller 

with an associated programming system. 
25 FIG 5 shows the run level model of the universal controller. 

FIG 6 shows as an object-oriented structural diagram a technology packet 

comprising a code part, parameter, firmware configuration, 
technology object type, programming language features 
component, and declaration part. 
30 FIG 7 shows as an object-oriented structural diagram technology object 

types for a plastics technology packet. 
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FIGS 



shows how the descriptive or parameterization information from a 
data source is made available via a converter to the engineering 
system, the run time system, and an output medium. 



5 The presentation in FIG 1 is a structural diagram showing that parallel 

operation of a PLC and a motion controller NC takes place to control a technical 
process TP1. The PLC and the motion controller NC each contain a run time 
system RTS1 and RTS2, respectively. Communication between the two 
controllers takes place via a special auxiliary resource; the example shown is a 

10 bi-directional communications channel K. The controllers are typically 
programmed by the user in different programming languages with different 
generation interfaces, in other words, by means of separate programming or 
engineering systems P1, ES1, and P2, ES2. The significant disadvantage of this 
conventional configuration is, first, the cumbersome communication between the 

15 two systems, and second, the separate and different programming and 

engineering systems P1, ES1, and P2, ES2. The actual technical process TP1 is 
controlled via inputs and outputs EA1 , EA2 of the controllers. There are 
information paths 11 and 12, on which the programs are loaded into each 
controller, between the programming system P1 and the PLC SPS, and between 

20 the programming system P2 and the numerical controller NC. 

The diagram in FIG 2 shows the significant run levels of a classic 
programmable logic controller (PLC; FIG 1), arranged according to their priority. 
Increasing priority is indicated by an arrow. At the level of lowest priority, as 

25 indicated by a dotted line, two different tasks are processed, namely, a free 
cycle, i.e., "user-level free cycle," and a background system-level, i.e., "system- 
level background," in a round-robin or time-sharing procedure. Communication 
tasks, for example, are allocated to the background system-level. When this is 
followed by a clocked user-level, designated the "user-level, clocked," 

30 parameters can be assigned for the call-up frequency of the tasks or programs of 
this level- Monitoring is performed to determine whether the processing of a user 
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program on this clocked level has been concluded in time before the start event 
occurs again. If the clock time elapses without the user program of the allocated 
level having been completely processed, a corresponding task is started in a 
"user-level for asynchronous errors" that is of next highest priority. The user can 
program out the handling of error statuses in this "user-level for asynchronous 
errors." 

The "user-level, clocked" is followed by a "user-level events." Reactions to 
external or internal events take place within this "user-level events." A typical 
example of such an event is when a limit value is exceeded. Operating system 
tasks which ensure the operating procedure of the PLC are located in a "system- 
level, high priority." 

The diagram in FIG 3 shows the essential run levels of a motion controller 
(NC; FIG 1). Here, too, the individual levels are arranged hierarchically 
according to their priority, as symbolized by an arrow. A "system-level 
background" and a "user-level sequential" have the same priority, namely the 
lowest. This association, based on similarity of tasks, is symbolized by a dotted 
line, as in FIG 2. The tasks of the "user-level sequential" are processed together 
with the tasks of the "system-level background" in a round-robin procedure. 
Typical tasks of the "system-level background" are, for example, communication 
tasks. The program parts programmed by the user for the actual controller run in 
the "user-level sequential." If the controller encounters a movement or 
positioning command in one of these program parts, a suspend is set, that is to 
say, the user program is interrupted at this point. The execution of this 
movement or positioning command takes place in a "system-level, clocked" with 
highest priority. Each position controller that runs in the "system-level, clocked" 
carries out this movement or positioning command. After the command has 
been executed, the system jumps back to the "user-level, sequential," and the 
user program interrupted by the suspend is continued by a resume at the same 
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point. In addition to the position controllers mentioned above, the "system-level, 
clocked" also contains the interpolation part of the controller. 

A "user-level, clocked" is also constructed on the level of lowest priority. 
Cyclical tasks run here, for example, regulator functionalities. 

A subsequent "user-level, events" includes such tasks as react to external 
or internal events. Such events might be alarms, for example. 

The diagram in FIG 4 shows a technical process TP2 being controlled by 
a combined PLC/NC controller UMC. The acronym UMC stands for UNIVERSAL 
MOTION CONTROL. The controller UMC and the associated technical process 
TP2 are connected bi-directionally via inputs/outputs EA3. The combined 
PLC/NC controller is programmed via a shared programming system P3 or 
engineering system ESS, where the engineering system ESS presents a 
convenient interface for the programming system PS, as in FIG 1 . The programs 
created in this way are transferred via an information path IS into a run time 
system RTSS of the universal motion controller UMC. 

The diagram in FIG 5 shows the run level model of the universal motion 
controller. The prioritization of the levels is indicated as in the foregoing by an 
arrow pointing in the direction of the highest priority. The lowest-priority group of 
levels is the "level group, background processing." It consists of a "system-level 
background," a "user-level, free cycle," and a "user-level, sequential." The tasks 
of these three levels, which are of equal priority (indicated by the dotted outlines), 
are processed cyclically in a round-robin procedure. A higher-priority "run level" 
subsequent to the "level group background processing" is a user-level FA that is 
freely plan-able by the user to meet specific requirements, indicated by a double 
outline, for alarm and/or even and/or control and/or other cyclical tasks. This 
user-level FA thus consists explicitly of four types of levels, which in turn can be 
ranked bv the user within the user-level FA according to their priority. 
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Type 1 : user-level, Event 
Type 2: user-level, Alarm 
Type 3: user-level, clocked 
5 Type 4: system-level, parameterized 

Levels of these types can be freely arranged by the user within the user-level FA, 
each with priorities that can be assigned by the user. Thus, the user has the 
possibility of obtaining a configuration for the universal motion controller that is 
10 optimal for the requirements and constraints of the control task and the technical 
process to be controlled. 

In the "user-level, event," for example, tasks are arranged that react to 
inputs from peripheral devices. In the "user-level, alarm," for example, tasks are 

15 arranged that react when limit values are exceeded. The "user-level, clocked" 
contains cyclical tasks that can be programmed by the user. Programs that can 
be loaded from external sources can be integrated into the "system-level, 
parameterized." This makes it possible to expand the universal motion controller 
dynamically to include additional technological functionalities. Typically, tasks for 

20 slow control or monitoring responsibilities (for example, tasks with cycle times in 
the range of 100 ms) are loaded into this "system-level parameterized." 

The level of next highest priority in the run level model for the universal 
motion controller is a "user-level for asynchronous errors." In this level, the user 

25 can program out the handling of error statuses, similar to with a PLC. For 
example, this "user-level for asynchronous errors" is where tasks reside that 
react to technological alarms. Within this "user-level for asynchronous errors," 
the user can also parameterize a specific number of levels for a product 
configuration. For the sake of clarity, the diagram does not include details about 

30 this. Thus, the user can allocate a defined priority to certain error events as 
needed. 
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Next is the "event system-level." The tasks in this "event system-level" 
react to critical internal or external events, for example, emergency shutdown. 

5 The next level is an "interpolator level." It contains a "clocked system- 

level" and a "user-level." 

The highest-priority level is the "position control level." It also contains a 
"clocked system-level" and a "user-level." The user-levels of the position control 
10 level and interpolator level contain tasks that are called up in the cycle of the 
position controller or interpolator. The run time of these tasks is monitored; if a 
time established by the system is exceeded, the level is canceled and an 
asynchronous error is initiated in the "user-level for asynchronous errors." 

15 The position controller has a higher priority than the interpolator; in other 

words, the position controller cannot be interrupted by the interpolator, but the 
position controller can interrupt the interpolator. 

Within the individual run levels in the run level model for the universal 
20 motion controller, additional prioritizing layers can be provided in addition to 
those already mentioned. 

The diagram in FIG 6 shows a technology packet TP and its components 
as a 00 structure diagram, where the cardinalities are indicated by consecutive 
25 numerical notation: 

a) executable code parts (Code) 

b) parameters (PAR) 

c) firmware configuration (FWK) 

d) at least one technology object type (TO) 
30 e) programming language features (SPR) 

f) declaration and description part (ACC) 
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Code parts 1 to n (for example, C functions) are used for control guidance 
or position control or for another technology, for example. The code parts can 
contain, among other things, commands for temperature guidance, temperature 

5 control, or special technologies such as presses or plastic processing. The 
firmware configuration FWK determines how these code parts are mounted into 
the system-levels in the run level model of the controller and in what sequence 
they are processed, that is, executed. The FWK also includes the information 
about the system-level into which a code part is to be integrated, and, if several 

10 code parts are integrated in one system-level, in what sequence these code parts 
should be processed. 

The parameters part PAR contains interface and control parameters for 
the engineering system (ES; FIG 1 , FIG 4, FIG 8) as well as the mechanisms for 
15 the run time system (RTS; FIG 1, FIG 4, FIG 8) that enable parameterization. 
Thus, the user can parameterize instances of technology object types TO in a 
technology packet TP according to her/his requirements. 

Using the programming language features SPR 1 to n of a technology 
20 packet TP, the library of available programming language features of the 
engineering system (ES; FIG 1 , FIG 4, FIG 8) can be expanded to include 
commands and operators that are sufficient and practical for the underlying 
technology packet TP with its associated technology objects TP 1 to n. 
Programming language features SPR must be loaded into the engineering 
25 system (ES; FIG 1, FIG 4, FIG 8) and into the run time system (RTS; FIG 1 , FIG 
4, FIG 8) of the controller. After such programming language features (for 
example, "high temperature") have been installed in the engineering system (ES; 
FIG 1 , FIG 4, FIG 8), they are known in the compiler and in the interface or 
browser of the engineering system (ES; FIG 1 , FIG 4, FIG 8) and can be used 
30 directly by the user in her/his user programs. Plug & Play technology ensures 
that known programming language features are available in the engineering 
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system (ES; FIG 1 , FIG 4, FIG 8) as well as the executable code piece in the run 
time system (RTS; FIG 1, FIG 4. FIG 8). The user thus uses the specification of 
the programming language features and no longer needs to be concerned with 
implementation in the run time system (RTS; FIG 1, FIG 4, FIG 8), In FIG 8, 
5 discussed below, the interplay of loading, using, and processing programming 
language features SPR of technology packets TP is explained in greater detail. 

To return to FIG 6: The ACC component of a technology packet TP 
contains the description of all programming language elements contained in the 

10 technology packet TP, the description of all system variables, and the description 
of all types used in the technology packet TP. The ACC component thus 
corresponds to a declaration and description part for the technology packet TP. 
This ACC component is loaded principally into the run time system of the 
controller (RTS; FIG 1, FIG 4, FIG 8). This ensures that all information relevant 

15 to existing technology packets TP and technology object types TO are located in 
the run time system of the controller and that control and monitoring devices (for 
example, operator panels) can easily be connected. 

The following table shows where the elements in the technology packet 
20 TP are loaded within the controller: either into the engineering system (ES; FIG 
1, FIG 4, FIG 8) or into the run time system (RTS; FIG 1, FIG 4, FIG 8), or into 
both the engineering system (ES; FIG 1 , FIG 4, FIG 8) and the run time system 
(RTS; FIG1, FIG 4, FIG 8). 
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executable code 


Code 


RT 


parameterizing interface (and corresponding knowledge 
about individual parameters) 


PAR 


ES 


configuration information (information about how and 
where the parts are linked into the run system) 


FWK 


ES + 
RT 


user interface (commands (MOVE, POS, ...), SFCs, 
SFBs, system variables, ...) 


SPR 


ES + 
RT 


user interface (graphic information) 


SPR 


ES 


description information for system variables, alarms,... 


ACC 


ES + 
RT 


object types (technological objects) 


TO 


ES + 
RT 


version information for consistency between RT, 
packets, and objects 


ACC 


ES + 
RT 



The diagram in FIG 7 shows as examples possible technology object 
types (TO; FIG 6) for a plastics technology packet TPK (TP; FIG 6) as an 00 
structure diagram. For plastic processing or production, one usually needs a 

5 temperature controller and a pressure controller. The pressure that must be 
regulated by the pressure controller DR is typically produced by a single axis A, 
which compresses the material mass. Two temperature controllers are provided 
for temperature regulation in this example: a fast temperature controller TRS 
and a slow temperature controller TRL. As is apparent in the 00 structure 

10 diagram, the slow temperature controller TRL and the fast temperature controller 
TRS are derived from the general temperature controller TR. The two 
temperature controllers TRS and TRL, the pressure controller DR, and the axis A 
are represented in this plastics technology packet by four technology object types 
TO, viz., TRS, TRL, DR, and A. The cardinality (numeral 1) indicates that exactly 

15 one fast temperature controller TRS and one slow temperature controller TRL, as 
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well as exactly one pressure controller DR and one axis A are used in this 
example. The fast temperature controller TRS can conceal a PID controller, for 
example, while the slow temperature regulator can conceal a P controller, for 
example; these, however, are implementation details that do not concern a user 
5 of the functionalities of these technology objects in the engineering system (ES; 
FIG 1 , FIG 4, FIG 8). Thus, a user can use the functionalities of these 
technology object types (TO; FIG 6) in the engineering system (ES; FIG 1, FIG 4, 
FIG 8) without being concerned about implementation details. 



10 The diagram in FIG 8 shows that communication takes place to the 

converter U via the information path 14 from a data source D that contains the 
description information for system variables as well as alarms and/or commands 
as needed. The converter U generates parameterization information from the 
input data for the engineering system ES4, for the output medium AM, and for 

15 the run time system RTS 4. The converter U is called up before compilation of 
the run time or engineering system software. It generates sources that are then 
complied during generation of the run time or engineering system software. The 
parameterization information is transferred from the converter U to the 
engineering system ES4 on the information path 15. The parameterization 

20 information generated by the converter U for documentation is forwarded via the 
information path 16 to the output medium AM, represented in FIG 8 by a printer. 
An online help file on the screen is also conceivable as an output medium, for 
example. The parameterization information generated by the converter for the 
run time system is loaded via the information path 17 into the run level model AE 

25 of the run time system RTS4. 



The converter U is always called up when it receives new 
parameterization information from the data source D via the information path 14. 
In such a case, the converter U generates new sources for documentation, for 
30 the run time system RTS4, and for the engineering system ES4. 
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During controller operation, the system variables loaded into the 
engineering system are supplied with current data for the technical process by 
the run time system RTS4 via the information path 18. The user can perform 
additional inputs on the engineering system ES4 in accordance with the current 
5 status of the technical process (TP1 , TP2; FIG 1 or FIG 4). 

The run time system RTS4 can supply information (for example, alarms) 
to a device for close machine monitoring and control (represented in FIG 8 by an 
operator panel OP) via the information path 19. 

10 

The converter U does not appear during controller operation. The 
information paths 14, 15, 16, and 17 are used during generation of the controller 
software, but not during controller operation. Information paths 18 and 19 are 
used during controller operation. 

15 
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